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A  VIEW  OF  OBJECT-ORIENTED  PROGRAMMING 


B.  J.  MacLennan 
Computer  Science  Department 
Naval  Postgraduate  School 
Monterey,  CA  93940 


Abstract. 

Applicative  programming  languages  and  languages  for  data¬ 
flow  machines  are  often  described  as ^value-oriented  languages. 
Other  languages,  such  a  Smalltalk,  are  described  as  object- 
oriented.  LISP  has  been  described  as  both  value-oriented  and 
object-oriented.  What  exactly  do  these  terms  mean? 


This  paper  attempts  to  identify  and  clarify  the  differences 
between  values  and  objects  and,  hence,  between  value-oriented  and 
object-oriented  languages.  The  paper  then  turns  to  the  question 
of  whether  objects  should  be  included  in  applicative  languages 
and  the  role  they  can  fill  in  those  languages.  The  remainder  of 
the  paper  is  a  proposal  for  one  approach  to  a  true  object- 
oriented  programming.  This  includes  both  an  informal  description 
of  object-oriented  programming  constructs  and  a  formal  semantics 
for  these  constructs.  Nondeterminacy ,  synchronization  and 
recovery  from  failures  are  briefly  discussed. 


1.  Introduction 
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1.1  What  are  Values? 


Value-oriented  programming  can  be  described  as  programming 
without  the  use  of  variables,  side-effects,  or  an  updatable 
memory.  The  basic  idea  is  that  the  value  of  an  expression 
depends  only  on  its  operands,  and  that  the  only  effect  of  execut¬ 
ing  an  expression  is  the  value  it  returns.  Thus  the  operators  in 
an  expression  are  mathematical  functions. 

Almost  every  programming  language  has  a  value-oriented  sub¬ 
set:  its  arithmetical  expressions.  The  value  of  an  expression 
such  as  (3  +  2)  depends  only  on  its  input  operands  (3  and  2,  in 
this  case) ,  and  the  only  effect  of  executing  the  expression  is 
the  value,  5,  returned. 

One  of  the  desirable  characteristics  of  values  is  their 
predictability.  We  can  tell  the  interfaces  of  an  arithmetic 
expression  by  simple  inspection.  Since  all  of  the  functions  are 
side-effect-free,  all  of  the  inputs  and  outputs  of  each  functions 
are  manifest.  This  simplifies  manipulation  of  value-oriented 
expressions,  and  simplifies  proving  properties  about  them. 

What  is  it  about  va'ues  that  give  them  these  characteris¬ 
tics?  We  have  noted  that  the  most  value-oriented  parts  of  most 
programming  languages  are  there  most  mathematical  parts,  so  it  is 
no  surprise  to  find  that  mathematics  is  that  discipline  that  most 
consistently  deals  with  values.  Hence,  we  can  discover  many  of 
the  characteristics  of  values  by  studying  mathematical  entities. 


What  are  these  characteristics?  The  fundamental  property  of 
mathematical  entities  is  that  they  are  abstractions  (concepts, 
universals).  For  example,  the  number  two  is  an  abstraction  that 
subsumes  as  its  particulars  all  of  the  various  pairs,  whether 
they  exist  in  reality  or  our  imagination,  or  in  the  present,  or 
the  past  or  future.  Because  mathematical  entities  are  abstrac¬ 
tions,  they  do  not  change.  Particular  pairs  may  come  into  or  go 
out  of  existence,  but  the  abstraction  two  remains.  Also,  the 
number  of  marbles  in  a  bag  may  be  subsumed  by  the  abstraction  two 
at  one  time,  and  the  abstraction  three  at  a  later  time,  but  nei¬ 
ther  abstraction  has  been  altered.  Similarly,  it  is  not  meaning¬ 
ful  to  speak  of  the  creation  or  destruction  of  a  value;  mathemat¬ 
ical  equations  such  as  5  *  2+3  describe  timeless  relationships 
among  values,  not  descriptions  of  their  creation,  modification, 
or  destruction.  In  this  sense  values  are  atemporal;  that  is,  the 
concept  time  does  not  apply  to  them.  It  is  just  as  meaningless 
to  apply  time  concepts  to  a  number  as  it  is  to  apply  color  con¬ 
cepts. 


Another  characteristic  of  values  is  that  they  are  universal ? 
that  is,  they  are  not  particular.  This  is  because  an  abstraction 
is  coextensive  with  the  particulars  it  subsumes.  For  example, 
the  abstraction  two  is  coextensive  with  all  particular  pairs,  and 
conversely,  anything  coextensive  with  all  particular  pairs  is  the 
abstraction  two .  The  result  of  this  is  that  it  makes  no  sense  to 
talk  of  "this  number  two"  or  "that  number  two"  or  to  ask,  "How 
many  number  two's  are  there?"  These  are  concepts  that  apply  to 
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particular  things,  and  values  are  universals,  not  particulars. 

The  characteristics  of  values  can  be  summarized: 
t  values  are  atemporal; 
t  values  are  immutable; 

♦  values  are  neither  created  nor  destroyed; 
t  values  are  universal. 

It  can  be  seen  now  that  applicative  programming  is  essen¬ 
tially  value-oriented  programming.  In  a  purely  applicative 
language,  there  is  no  assignment  operation  and  no  idea  of  state. 
Functions  compute  values  solely  on  the  basis  of  their  inputs,  and 
have  no  side-effects.  This  is  of  cou'rse  why  applicative  program¬ 
ming  is  so  mathematical;  it  J^s  mathematics. 


Consider  an  applicative  subset  of  LISP  (i.e.,  without  RPLACA 
and  RPLACD,  and  with  EQ  restricted  to  atoms).  In  this  language 
lists  can  be  treated  like  mathematical  entities  (specifically, 
tuples)  and  the  list  processing  operations  can  be  treated  like 
mathematical  functions  on  these  entities.  Lists  may  be  computed, 
but  they  are  not  modified,  created,  destroyed,  copied,  or  shared. 
Again,  applicative  programming  (value-oriented  programming)  is 
essentially  mathematics. 


1 . 2  What  are  Objects? 


There  is  probably  more  confusion  about  the  nature  of 


object-oriented  programming  than  about  the  nature  of  value- 


oriented  programming  (see,  for  example,  [Lomet76] ,  [Lomet80] , 
[Robson81] ,  [Rentsch82]  and  [MacLennan82] ) .  In  this  section  we 
identify  some  of  the  characteristics  of  objects  and  object- 
oriented  programming. 

In  object-oriented  programming  systems  such  as  Smalltalk, 
all  computation  is  viewed  as  simulation.  Here,  programming 
language  objects  correspond  to  real-world  objects,  and  manipula¬ 
tions  of  real-world  objects  are  simulated  by  sending  messages  to 
the  programming  language  objects.  In  Smalltalk,  programming 
language  objects  are  grouped  into  classes  (i.e.,  abstractions)  of 
similarly  behaving  objects. 

What  is  an  object?  We  can  get  a  clue  to  its  nature  from  the 
common  use  of  the  term.  In  common  usage  an  object  is  a  material 
entity  existing  in  space  or  time.  Let  us  consider  what  it  means 
for  a  programming  language  object  to  exist  j_n  time .  This  means 
that  it  persists  as  an  identifiable  entity  through  some  period  of 
time,  which  in  turn  means  that  it  can  come  into  existence  at  some 
point  in  time  (i.e.,  be  created)  and  that  it  can  go  out  of 
existence  at  some  point  in  time  (i.e.,  be  destroyed).  This  is  a 
common  characteristic  of  objects  in  computers;  for  example, 
objects  in  Smalltalk  and  Simula  are  created  by  explicit  request 
(the  new  operation) ,  and  are  destroyed  by  a  garbage-collector 
when  they  are  no  longer  accessible. 


Just  as  real  objects  exist  jji  space ,  programming  language 


objects  may  enter  into  a  number  of  relationships,  spatial  and 
otherwise,  with  other  objects.  For  example,  one  object  may  be 
part  of  another  object,  or  (in  an  operating  system)  the  owner  of 
another  object.  In  a  system  like  Smalltalk  the  attributes  of  an 
object  are  represented  by  instance  variables,  whose  values  are 
themselves  objects.  In  data  bases  intended  to  represent  real- 
world  knowledge,  nodes  representing  objects  are  connected  by 
labeled  arcs  representing  relationships  among  the  objects. 

Real-world  objects  not  only  exist  in  time,  they  also  change 
through  time.  That  is,  various  factors  can  alter  an  object's 
relationships  with  other  objects  (such  as  position)  and  an 
object's  other  attributes  (such  as  size).  This  is  in  marked  con¬ 
trast  to  values,  which,  as  we  have  seen,  are  immutable.  Another 
way  to  state  this  is  that  at  any  point  in  time  an  object  has  a 
state,  which  is  the  sum-total  of  its  relationship  with  all  other 
objects  in  the  system.  Various  laws  then  determine  how  the  state 
of  an  object  can  change  in  time.  Of  course,  the  ultimate  change 
in  state  that  any  object  can  undergo  is  its  creation  or  destruc¬ 
tion. 

In  systems  like  Smalltalk  the  instance  variables  determine 
the  state  of  an  object  and  the  methods  defined  in  the  object's 
class  determine  the  object's  behavior  in  time. 

The  mutability  of  objects  leads  to  another  of  their  impor¬ 
tant  characteristics:  the  notion  of  sharing.  We  have  said  that 
values  are  universal,  i.e.,  that  the  concept  of  instance  does  not 
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apply  to  them.  This  is  not  the  case  for  objects.  Since  only  a 
finite  number  of  properties  are  representable  on  a  finite  com¬ 
puter  system,  it  is  quite  possible  that  two  programming  language 
objects  have  all  the  same  properties,  yet  represent  distinct 
real-world  objects.  It  is  of  course  quite  common  in  object- 
oriented  programs  to  have  two  different  objects  that  at  some 
ooint  in  time  have  the  same  attributes.  Thus,  objects  have  an 
identity  independent  of  their  state,  which  makes  them  particular 
rather  than  universal .  If  two  entities  share  access  to  the  same 
object,  then  if  one  entity  changes  the  state  of  the  object,  the 
change  will  be  visible  to  the  other  entity.  Conversely,  if  the 
two  entities  each  have  access  to  distinct  objects  (that  might 
have  the  same  state)  then  a  change  to  the  state  of  one  will  not 
directly  cause  a  change  to  the  state  of  the  other.  The 
shared/non-shared  distinction  is  of  course  familiar  from  object- 
oriented  programming  systems. 

The  characteristics  of  objects  can  be  summarized: 

♦  objects  are  temporal;  they  exist  in  time; 

♦  objects  are  mutable,  and  have  a  state; 

t  objects  can  be  created  and  destroyed; 

♦  objects  are  particular,  and  can  be  shared. 

1 . 3  Objects  in  Applicative  Languages. 


It  would  seem  that  objects  should  be  excluded  from  applica- 


tive  programming  systems.  They  have  many  of  the  undesirable 
characteristics  of  imperative  languages,  such  as  a  changeable 
state,  a  strong  dependence  on  the  time  sequence  of  events,  and 
complications  arising  from  the  notion  of  sharing.  In  this  sec¬ 
tion  we  will  argue  that  this  is  not  the  case,  that  objects  have  a 
role  in  applicative  languages. 

The  reason  for  this  is  simple:  the  purpose  of  a  program  is 
often,  directly  or  indirectly,  the  modeling  of  some  aspect  of  the 
real-world.  Further,  the  aspects  that  we  are  interested  in 
modeling  often  involve  the  changing  relationships  among  real- 
world  objects.  The  obvious  approach  is  to  use  programming 
language  objects  to  model  the  real-world  objects. 

Given  this  observation  it  is  not  surprising  that  the  con¬ 
cepts  of  object-oriented  programming  first  arose  in  connection 
with  simulation  languages,  in  particular  Simula  [Dahl70] . 
Smalltalk,  one  of  the  most  widely  known  object-oriented 
languages,  is  based  on  Simula  and  takes  the  view  that  all  pro¬ 
gramming  in  simulation  [Kay77] .  For  these  reasons  many  basic 
ideas  of  simulation  (see  for  example  [Pr i tsker79] ,  Chapter  3  and 
[Maisel72] ,  Chapter  1)  are  fundamental  to  our  notion  of  objects. 

It  will  be  objected  that  applicative  languages  do  not  need 
objects  to  model  the  changing  state  of  real-world  objects.  The 
technique  is  familiar  from  the  use  of  denotational  semantics  to 
describe  imperative  languages.  The  total  state  of  the  system  is 
described  by  some  value ,  such  as  a  sequence  or  a  function.  This 


value  is  the  input  to  an  applicative  state-transition  function 
that  computes  the  value  representing  the  new  state. 

Although  this  works,  it  is  not  very  satisfactory.  Functions 
tend  to  accumulate  large  numbers  of  arguments,  or  highly  struc¬ 
tured  composite  arguments,  that  represent  the  state.  This 
defeats  the  goals  of  applicative  programming  by  destroying  the 
clarity  and  mathematical  tractability  of  programs.  The  problem 
becomes  acute  in  operating-systems,  real-time  systems,  graphics 
software,  data-base  systems,  and  of  course  in  explicit  simula¬ 
tions.  For  this  reason  the  remainder  of  this  paper  will  discuss 
how  objects  can  be  best  reconciled  with  applicative  languages. 

We  must  first  note  an  obvious  points  the  entire  state  of 
the  universe  cannot  be  simulated  inside  a  computer.  Therefore, 
it  becomes  necessary  to  select  the  subpart  of  the  universe 
relevant  to  the  problem,  and  the  appropriate  level  of  abstraction 
for  the  simulation. 

The  result  is  that  the  state  of  the  simulation  is 
represented  by  a  finite  number  of  objects  connected  by  a  finite 
number  of  relationships.  As  the  simulation  progresses  the  rela¬ 
tionships  among  the  objects  may  change  and  objects  may  be  created 
or  destroyed. 

The  relations  and  objects  described  above  can  be  termed 
corresponding  objects  and  relations  because  they  correspond  to 
the  objects  and  relations  in  the  real-world  that  they  model.  The 
system  may  also  contain  non-corresponding  objects  and  relations. 


These  do  not  necessarily  correspond  to  any  real-world  objects  or 
relations,  but  are  used  to  implement  the  corresponding  objects 
and  relations.  Thus,  the  distinction  between  corresponding  and 
non-corresponding  objects  and  relations  is  analogous  to  the  dis¬ 
tinction  in  object-oriented  programming  languages  between  the 
publicly  visible  objects  and  their  abstract  properties  on  one 
hand,  and  the  private  objects  and  attributes  used  to  implement 
the  public  ones  on  the  other. 

The  non-corresponding  objects  are  analogous  to  theoretical 
entities  in  a  scientific  theory:  we  cannot  in  general  infer  from 
them  the  existence  of  corresponding  real-world  objects.  Thus, 
like  the  implementation  details  of  a  Smalltalk  or  Simula  object, 
it  is  usually  desirable  if  the  non-corresponding  objects  and 
relations  be  hidden.  This  can  be  accomplished  by  the  proper  con¬ 
trol  of  name  contexts.  That  is,  an  entity  can  only  gain  access 
to  an  object  or  relation  if  that  object  or  relation  has  a  name  in 
a  context  accessible  to  that  entity.  This  is  analogous  to  having 
a  capability  for  an  object  in  an  accessible  capability  list. 
Generally,  only  the  implementor  of  a  class  of  objects  will  have 
access  to  a  context  naming  the  non-corresponding  objects  and 
relations  used  to  implement  that  class  of  objects.  Thus,  infor¬ 
mation  hiding  is  easily  accomplished. 

The  objects  and  relations  that  are  intended  to  be 
corresponding  can  be  made  public  by  giving  them  a  name  in  a  more 
widely  accessible  context.  Of  course,  the  changeable  name  con¬ 
texts  that  are  used  to  accomplish  this  control  are  themselves 
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objects . 

How  do  the  relations  among  objects  come  to  be  changed?  In 
the  real-world  such  changes  are  expressed  by  causal  laws,  which 
state  how  certain  relations  holding  among  objects  cause  these 
relations  to  change  in  time.  These  laws  are  usually  expressed  as 
a  conditional  statement  about  some  class  of  objects.  For  exam¬ 
ple,  "an  electron  in  conditions  C  will  act  in  manner  A." 

The  same  approach  can  be  used  for  controlling  the  changing 
relations  among  objects  in  a  programming  system.  This  is  similar 
to  what  is  done  in  object-oriented  languages  like  Smalltalk: 
classes  of  objects  are  defined  which  behave  in  the  same  way  in 
various  message-receiving  situations.  Thus,  the  methods  of 
Smalltalk  can  be  thought  of  as  causal  laws. 

How  do  these  ideas  relate  to  applicative  programming 
languages?  Note  that  values  enter  into  the  universe  of  objects 
in  several  places.  First,  certain  attributes  of  objects  (e.g., 
weight)  and  relations  among  objects  (e.g.,  distance)  will  be 
values.  Second,  the  relations  that  hold  among  objects  at  any 
given  time  are  themselves  values,  since  relations  are  mathemati¬ 
cal  abstractions. 

At  each  instant  of  time  the  causal  laws  must  determine  new 
relations  to  be  associated  with  the  relation-names  at  the  next 
instant  of  time.  These  changes  are  expressed  as  transactions 
that  add  tuples  to,  or  delete  tuples  from,  the  relations.  Appli¬ 
cative  programs  can  be  used  to  determine  the  values  to  be 
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associated  with  the  value-bearing  attributes  of  an  object.  Thus, 
value-oriented  and  object-oriented  programming  techniques  can  be 
used  together  in  a  way  that  exercises  the  advantages  of  each. 
Values  and  pure  functions  are  used  to  model  abstractions  and 
their  relationships,  while  objects  and  causal  laws  are  used  to 
model  real-world  objects  and  their  behavior. 

2.  Intension  versus  Extension 

It  is  necessary  to  distinguish  between  the  intension  and 
extension  of  the  relations  in  the  computer  that  are  used  to  model 
corresponding  external  relationships  and  properties.  Two  rela¬ 
tions  have  the  same  intension  if  they  are  intended  to  model  the 
same  external  relationships  or  properties.  Two  relations  have 
the  same  extension  (at  a  given  point  in  time)  if  they  apply  to 
the  same  objects  (or  tuples  of  objects  and  values) .  Notice  that 
two  relations  may  be  extensionally  the  same  even  though  they  are 
intensional ly  different.  For  example,  at  a  given  point  in  time, 
the  same  three  objects  may  satisfy  both  the  relations  "blue"  and 
"round,"  but  this  does  not  imply  that  "blue"  and  "round"  model 
the  same  property.  That  is,  "blue"  and  "round"  have  the  same 
extension  but  different  intensions.  Also,  notice  that  one  of  the 
objects  might  at  the  next  instant  become  "non-blue"  while  remain¬ 
ing  "round."  Thus,  although  the  intension  of  relations  remains 
fixed  their  extension  can  vary  in  time.  From  time  to  time,  rela¬ 
tions  with  different  intension  can  coinciiently  have  the  same 
extension. 


The  same  distinctions  apply  to  objects.  The  intension  of  a 
computer  object  is  the  real-world  object  it  is  intended  to  model; 
the  extension  of  a  computer  object  is  the  set  of  relations  to 
which  it  belongs.  Thus  objects  with  different  intensions  can 
coincidently  have  the  same  extension. 

These  notions  of  intension  and  extension  might  seem  to  con¬ 
flict  with  Liebnitz'  doctrine  of  the  identity  of  indiscernibles , 
which  says  that  two  things  that  are  alike  in  every  way  are  ident¬ 
ical.  Symbolically, 

x  -  y  VPfP(x)  «=»  P  (y) } 

In  the  real  world  two  things  which  agree  in  every  property  and 
relationship  are  the  same  thing.  In  a  computer  system,  however, 
it  is  not  possible  to  model  every  property  and  relationship;  it 
is  necessary  to  select  a  finite  number  of  these  that  are  relevant 
to  the  problem  at  hand.  Therefore  we  can  have  two  computer 
objects  that  are  intended  to  model  distinct  real-world  objects, 
but  happen  to  agree  in  all  the  modeled  properties  and  relation¬ 
ships.  That  is,  the  two  computer  objects  have  different  inten¬ 
sions  but  the  same  extensions.  These  ideas  are  developed  further 
in  [MacLennen73 ]  and  [*lacLennan75]  ,  Chapter  3,  which  present  a 
mathematical  theory  of  intensional  relations  and  sets. 

How  can  a  programming  system  distinguish  intensional ly  dis¬ 
tinct  relations  that  happen  to  have  the  same  extension?  Mthough 
there  are  a  number  of  solutions  to  this  problem,  the  simplest  is 
to  associate  a  unique  ID  with  each  intens iona lly  distinct  object 
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or  relation.  Then,  two  objects  or  relations  are  distinct  if  and 
only  if  they  have  distinct  IDs.  At  each  point  in  time  each  rela¬ 
tion  ID  is  associated  with  a  relation  (i.e.,  a  set  of  tuples) 
that  defines  the  relation's  extension. 

Notice  that  these  IDs  are  internal  identifiers  analogous  to 
references  or  capabilities;  they  have  no  connection  with  any 
names  that  programmers  might  use  to  refer  to  these  objects  or 
relations.  In  fact,  we  will  see  later  (Section  7)  that  program¬ 
mers  manipulate  objects  and  relations  by  giving  names  to  their 
IDs. 

3 .  Condition-Action  Rules 

We  describe  the  behavior  of  objects  by  using  causal  laws  of 
a  special  form,  condition-action  rules .  A  condition-action  rule 
says  that  if  some  objects  are  in  a  certain  situation  they  will 
act  in  a  certain  way.  That  is,  if  certain  relations  do  or  do  not 
hold  for  a  particular  objects,  then  those  objects  will  establish 
or  disestablish  certain  other  relations.  We  write  these  rules  in 
the  form 

<cause>  =**  <effect> 

where  <cause>  defines  the  conditions  under  which  the  objects  act, 
and  <effect>  defines  the  actions  that  they  take  under  those  con¬ 
ditions.  These  rules  are  very  similar  to  production  rules;  we 
explore  the  differences  later  (Section  9).  Next  we  will  discuss 
the  effect  part  of  rules;  the  cause  part  is  discussed  later. 


We  use  a  prefix  notation  for  expressing  actions;  that  is,  we 

use 

P  (x,  y ,  z,  •  •  i  ) 

to  mean  that  the  tuple  <x,  y,  z,  ...>  is  to  be  added  to  the  rela¬ 
tion  P.  Similarly, 

-P  (x,  y,  z,  ...  ) 

means  that  the  tuple  <x,  y,  z,  ...>  is  to  be  deleted  from  the 
relation  P.  In  the  above  x,  y,  z,  ...  represent  either  simple 
variables  or  constructor  expressions,  that  is,  expressions  that 
construct  compound  structures  from  other  simple  or  compound 
structures.  For  example,  the  constructor  expression  cons(x,y) 
constructs  the  compound  structure  <cons,x,y>. 

Since  a  single  rule  can  cause  a  number  of  actions  to  occur, 
the  <effect>  part  of  a  rule  allows  the  specification  of  a  set  of 
additions  or  deletions.  For  example,  the  rule 

...  =>  Contents  (s , y) ,  Receive(x) 

causes  the  tuple  <s,y>  to  be  added  to  the  Contents  relation  and 
the  tuple  <x>  to  be  added  to  the  Receive  relation.  As  we  said, 
the  tuples  can  contain  the  results  of  constructor  expression 
evaluation.  For  example,  the  rule 

...  =>  Contents(s,  cons(x,y)),  a(s) 

causes  the  tuple  <s,  <cons,x,y>>  to  be  added  to  the  Contents 


relation,  where  <cons,x,y>  is  the  result  of  evaluating  cons(x,y) 
in  the  current  context.  The  names  "s,"  "Contents,"  "cons"  etc. 
must  be  bound  in  the  current  context,  which  is  discussed  later. 

Conditions  are  specified  by  pattern  matching.  In  a  simple 
case  such  as 


Push(s,x,a),  Contents (s ,y)  ... 

we  are  testing  if  there  is  a  tuple  <s,x,a>  in  th  e  Pish  relation 
and  a  tuple  <s,y>  in  the  Contents  relation.  The  meaning  of  this 
condition  depends  on  the  bindings  of  the  names  that  occur  in  it, 
"s,"  "x,"  "a"  etc.  in  this  case.  Any  name  that  is  bound  to  a 
value  or  object  ID  will  match  that  value  or  object  ID;  any  name 
that  is  unbound  will  match  any  value  or  object  ID  and  bind  the 
name  to  that  value  oi  object  ID.  In  the  above  example  suppose 
that  all  the  lowercase  names  are  initially  unbound.  Then 
Push(s,x,a)  will  match  any  triple  in  the  Push  relation  and  bind 
its  components  to  "s,"  "x"  and  "a."  Next,  Contents (s ,y)  will 
match  any  pair  in  the  Contents  relation  whose  first  element  is 
the  "s"  matched  in  the  first  condition.  If  this  match  succeeds 
then  "y"  will  be  bound  to  the  second  element  of  the  pair.  Thus 
we  have  tested  whether  any  object  is  both  a  first  member  of  Push 
and  a  first  member  of  Contents. 

The  above  conditions  have  a  side  effect  of  binding  the  names 
"s,"  "x,"  "y"  and  "a"  to  the  components  of  the  tuples  that 
satisfy  the  conditions.  These  bindings  remain  in  effect  during 
execution  of  the  effect  part  of  the  same  rule;  they  are  then 
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discarded.  This  allows  us  to  perform  actions  on  the  values  and 
objects  satisfying  the  condition. 

In  the  above  example  we  tested  for  the  presence  of  a  condi¬ 
tion;  we  can  also  test  for  the  absence  of  a  condition.  Had  we 
written 

Push(s,x,a),  -Contents (s ,y)  =»  ... 

we  would  have  executed  the  action  part  if  there  were  not  a  pair 
in  Contents  whose  first  element  was  the  same  as  the  first  element 
of  any  triple  in  Push. 

With  this  explanation  the  meaning  of  a  complete  rule  can  be 
understood.  Consider: 

Push(s,x,a)f  Contents (s,y)  =»  -Push (s,xra)  ,  -Contents (s ,y) , 

Contents(sr  cons(x,y)),  a(s) 

This  means  that  if  the  Push  relation  holds  for  some  objects  s,  x 
and  a,  and  if  s  holds  the  Contents  relation  to  some  object  y, 
then  perform  the  following  actions: 

1.  Disestablish  the  Push  relation  between  s,  x  and  a. 

2.  Disestablish  the  Contents  relation  between  s  and  y. 

3.  Establish  the  Contents  relation  between  s  and  cons(x,y). 

4.  Establish  the  a  relation  on  s. 

We  can  see  that  s  is  a  stack.  The  meaning  of  the  Push  relation 
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is  that  some  agent  is  attempting  to  push  the  object  x  on  stack  s 
and  is  expecting  an  acknowledgement  in  a.  The  stack  accomplishes 
this  by  altering  its  Contents  relation.  It  acknowledges  its 
action  by  placing  itself  in  the  Receive  relation.  An  alternative 
interpretation  is  that  some  agent  sends  the  message  Push(s,x,a) 
to  the  stack.  The  stack  responds  by  altering  its  Contents  and 
sending  the  stack  back  through  a.  Typically  Push  would  be  a 
corresponding  (public)  relation  and  Contents  would  be  a  non¬ 
corresponding  (private)  relation. 

The  above  rule  demonstrates  a  common  situation:  the  condi¬ 
tions  that  hold  in  the  cause  are  disestablished  in  the  effect. 
For  this  reason  we  define  an  abbreviation:  any  rule  with  .a  con¬ 
dition  of  the  form  *<nameXtuple>  can  be  replaced  by  a  rule  in 
which  this  condition  is  replaced  by  <name><tuple>  and  an  addi¬ 
tional  action  -<nameXtuple>  is  added.  Thus,  any  tuple  success¬ 
fully  found  by  a  match  of  this  kind  is  deleted  from  the  relations 
in  which  it  was  found  before  the  action  part  of  the  rule  is  exe¬ 
cuted.  This  automatic  updating  is  convenient  since  it  is  the 
usual  case.  Using  it  the  Push  rule  can  be  written: 

♦Push  (s,x,a)  ,  ^Contents  (s  ,y)  =*>  Contents(s,  cons(x,y)),  a(s) 

These  rules  are  similar  to  operation  nodes  in  a  data-flow 
language:  when  tuples  of  a  certain  form  arrive  in  the  input  rela¬ 
tions  Push  and  Contents,  the  rule  "fires"  by  removing  the  tuples 
from  the  input  relations  and  putting  other  tuples  in  the  output 
relations  Push  and  a. 
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Popping  from  a  stack  illustrates  the  use  of  more  complex 
patterns.  Consider 

*Pop(s,a),  *Contents(s,  cons(x,y))  **  Contents (s,y) ,  a(x) 

The  first  clause  in  the  condition  searches  for  any  pair  <s,a>  in 
the  Pop  relation.  The  interpretation  is  that  some  agent  is  ask¬ 
ing  a  stack  for  its  top  element  and  wishes  it  to  be  returned  in 
a.  The  second  clause  in  the  condition  searches  the  relation  Con¬ 
tents  for  any  pair  whose  first  element  is  that  same  stack  and 
whose  second  element  is  something  that  matches  the  pattern 
cons(x,y).  If  we  assume  that  "cons"  is  already  bound,  then  the 
pattern  cons(x,y)  matches  any  triple  whose  first  element  is  the 
value  of  "cons."  The  remaining  two  elements  of  this  triple  are 
bound  to  "x"  and  "y."  The  effect  of  this  clause  is  to  take  the 
triple  that  is  the  stack's  contents  and  decompose  it  into  its 
components.  Thus  this  rule  reverses  the  effect  of  the  Push  rule, 
as  expected.  Notice  that  rules  are  symmetric:  the  same  relation 
and  constructor  expressions  can  be  used  on  either  side. 

4 .  Indivisibility  of  Rules 

So  far  we  have  discussed  the  form  of  rules  but  not  the  exe¬ 
cution  cycle  of  the  abstract  machine  on  which  they  execute. 
Although  this  will  be  defined  precisely  in  Section  S,  Formal 
Semantics,  we  now  address  the  issue  informally.  The  basic  rule 
of  execution  is  that  on  each  cycle  of  the  abstract  machine  one 
rule  is  applied.  That  is,  out  of  all  the  rules  whose  conditions 
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are  satisfied,  we  arbitrarily  select  one  and  execute  its  actions. 
The  effect  of  this  is  that  rules  are  executed  indivisibly. 

The  indivisibility  of  rules  is  important  in  a  number  of 

applications  that  require  the  synchronization  of  concurrent 

activities.  For  example,  if  there  is  exactly  one  x  such  that 

MutEx(x),  then  we  can  ensure  the  mutual  exclusion  of  two 

processes  by: 

♦MutEx  (x)  ...  begin  process  A  ... 

...  finish  process  A  ...  =*»  Mutex(x). 

♦Mutex  (x)  =*»  ...  begin  process  B  ... 

...  finish  process  B  ...  =*  MutEx(x). 

Since  a  rule  is  executed  to  completion  in  one  cycle,  either  pro¬ 
cess  A  or  process  3  is  guaranteed  to  get  exclusive  access.  In 
the  next  section  we  apply  this  idea  to  a  simple  producer-consumer 
synchronization  problem. 

5 .  Examples 

In  this  section  we  present  several  simple  examples  of  sets 
of  rules.  First,  extending  the  examples  of  Section  3,  we  have 
these  rules  for  stacks: 

♦NewStack (a) ,  ♦Avail(s)  =»  Contents (s , ni 1 ) ,  a(s). 

♦Push  (s , x , a ) ,  *Contents (s,y)  =>  Contents (s , cons  (x , y) ) ,  a(s). 

♦Pop(s,a),  ♦Contents (s, cons (x,y) )  =»  Contents  (s,y)  ,  a(x). 

♦Destroy (s , a) ,  *Contents  (s, x)  =»  a(x). 

/ 
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Notice  that  we  have  added  rules  for  both  creating  and  destroying 
stacks.  The  creation  rule  fetches  an  unused  object  from  the 

relation  Avail  to  make  into  a  stack.  Typically  NewStack,  Push, 
Pop  and  Destroy  would  be  public  names  and  Contents  would  be 
private  to  the  implementor. 

We  could  have  added  to  these  rules  a  relation  Stack  (s)  that 
asserts  that  s  is  a  stack.  This  relation  would  effectively 

define  the  type  of  s.  It  is  not  necessary  to  define  this  rela¬ 
tion  since  we  can  classify  anything  in  the  first  position  of  a 

tuple  in  Contents  as  a  stack.  The  integrity  of  the  type  is 

preserved  by  keeping  the  Contents  relation  private  to  the  imple¬ 
mentor. 

To  see  how  concurrent  processes  can  use  this  model  for  syn¬ 
chronization,  consider  a  simple  producer  sending  messages  to  a 
consumer  through  an  unbounded  buffer.  An  agent  puts  a  message  m 
in  the  buffer  by  sending  Produce fm,p) .  An  agent  consumes  a  mes¬ 
sage  by  sending  Consume  (c)  and  receiving  the  next  message  m  by 
*c(m).  This  is  expressed  by  the  following  rules: 

♦Initialize  (a)  =>  Pindex(O),  Cindex(O),  a(0). 

♦Produce  (x, a)  ,  *Pindex(k)  =»  3uffer(k,x),  Pindex (Sue  (k ) )  ,  a(k). 
‘Consume  (a) ,  *Cindex(k),  *Buffer(k,x)  =»  Cindex (Sue (k ) ) ,  a(x). 
where  Suc(x)  denotes  the  successor  of  x. 

Notice  that  the  indivisibility  of  rules  ensures  that  simultaneous 
Produce  messages  will  get  distinct  Pindexes  and  that  simultaneous 
Consume  requests  will  get  consecutive  buffer  elements. 


6.  Notational  Extensions 


The  syntax  for  condition-action  rules  described  previously 
is  termed  the  canonical  form  for  rules.  In  this  section  we  make 
several  notational  extensions  to  the  canonical  form  to  simplify 
expressing  rules. 

6.1  Compound  Rules 

Suppose  we  wished  to  write  rules  that  perform  one  action  if 
P  contains  a  pair  of  the  form  <x,x>  and  a  different  action  if  it 
contains  any  other  pair  <x,y>.  The  following  to  rules  will  not 
accomplish  this,  since  a  pair  <a,a>  will  match  the  pattern 
P(x,y) : 

P (x,x)  =>  Action  1. 

P(x,y)  =*»  Action  2. 

What  we  would  like  to  say  is:  first  try  the  pattern  P(x,x)  and 
only  if  this  fails  try  P(x,y).  This  idea  can  be  expressed  by 
using  a  negative  condition: 

P(x,x)  =>  Action  1. 

~P(x,x),  P(x,y)  =»  Action  2. 

We  allow  the  following  notational  abbreviation  for  this  common 
case : 

P  (x,x)  =»  Action  1 

else  P(x,y)  =»  Action  2. 
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This  extends  in  the  obvious  way  to  more  that  one  else-arm  and  to 
more  than  one  condition  in  the  cause  parts. 

6 . 2  Sequential  Blocks 

Often  we  want  the  mechanism  of  an  object  to  move  sequen¬ 
tially  through  two  or  more  states.  This  can  be  programmed  expli¬ 
citly  by  using  a  relation,  say  to  represent  the  state  of  the 
object.  For  example, 


co 

=» 

Eg,  jrf(l,  v)  * 

**{1,  V>»  C1 

•  •  •  • 

E1#  tf(2,  v) • 

*srf  (n,  v)  •  cn 

En* 

where  v  represents 

all 

the  unbound  variables  of 

Cg.  This  allows 

a  rule  to  fire 

only 

if  the  object  is  in  the 

proper  state.  We 

allow  a  group  of  rules  of  the  above  form  to  be  written  as  a 
sequential  block: 

c0  =*  [B„;  Cx  -*  El(  ...  ,  Cn  »  En} 

The  semicolons  are  suggestive  of  the  sequential  execution  of 
statements  in  conventional  programming  languages.  Notice  that 
the  variables  in  Cg  essentially  become  global  variables  of  the 
entire  block. 

Sometimes  rules  in  sequential  blocks  have  empty  cause  parts, 
for  example  "=»E,"  since  the  rule  is  to  be  applied  uncondition¬ 
ally  when  the  object  is  in  the  proper  state.  In  these  cases  we 
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allow  the  arrow  to  be  dropped:  "E 


II 


6 . 3  Procedure  Calls 

The  communication  mechanisms  we  have  described  are  asynchro¬ 
nous,  that  is,  a  message  is  sent  by  an  action  such  as 
Lookup(d,n,a)  (a  request  to  look  up  name  n  in  directory  d  and 
return  the  result  in  a)  and  a  result  is  received  by  a  condition 
such  as  *a(x).  Any  amount  of  processing  might  be  done  by  the 
sender  between  the  Lookup  and  the  reply. 

In  many  situations  the  sender  cannot  go  on;  it  must  wait  for 
a  reply.  For  example, 

*R(n,a)  Lookup(  Public,  n,  Receive),  £(a). 

*Receive(s),  *S(a)  =*  Pop(s,a). 

where  we  assume  the  only  purpose  of  £  is  to  convey  a  from  the 
first  rule  to  the  second.  In  these  cases  we  are  doing  synchro¬ 
nous  communication.  Since  synchronous  communication  is  so  com¬ 
mon,  we  allow  the  above  example  to  be  written: 

*R(n,a)  =>  Pop(  Lookup[  Public,  nl  ,  a). 

The  square  brackets  indicate  that  Receive  is  to  be  passed  as  the 
last  argument  and  that  we  are  to  wait  for  a  reply  (through  the 
private  Receive  relation)  before  continuing.  \  relation  name 
followed  by  an  argument  list  in  square  brackets  is  termed  a  pro¬ 
cedure  call  or,  more  briefly,  a  call . 


Next  we  consider  a  slightly  more  complicated  example.  Sup¬ 
pose  that  we  have  two  nested  calls;  what  would  this  mean? 

*R(n,a)  =»  a{  Pop[  Lookupt  Public,  nl  ]  ) . 

If  we  reduce  this  in  the  same  way  as  the  previous  example  we  get 
the  three  rules: 

*R(n,a)  =*»  Lookup(  Public,  n,  Receive),  2>(n,a). 

*Receive{s),  *2(n,a)  =»  Pop (  s.  Receive),  S(n,a). 

*Receive(x),  *£(n,a)  =»  a (x) . 

A  problem  is  apparent:  The  last  two  rules  have  essentially  the 
same  left-hand  sides;  this  means  that  either  of  these  rules  could 
accept  the  result  returned  by  Lookup,  which  is  incorrect.  To 
ensure  the  proper  synchronous  communicat ion  these  rules  must  be 
more  tightly  bound.  Since  a  particular  instantiation  of  a  rule 
is  uniquely  determined  by  the  rule  and  the  bindings  performed  by 
the  cause  part,  we  can  tag  each  communication  with  this  informa¬ 
tion.  Therefore,  to  reduce  the  rule 

*R(n,a)  P(  Pop[  Lookup[  Public,  n]  ]  )  . 

to  the  canonical  form,  we  must  create  new  relations  5,  p  and  cr, 
and  replace  the  rule  by  these  three: 

*R(n,a)  =»  Lookup(  Public,  n,  p) ,  Z(n,a). 

2  (n ,  a)  ,  *p(s)  =»  Pop(s,<7). 

*2(n,a),  *<r(x)  =>  a(x). 

The  separate  private  relations  p  and  cr  are  used  to  distinguish 
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different  acts  of  communication  in  the  original  rule. 

This  process  can  be  generalized  in  a  straight-forward  way  to 
handle  effects  that  contain  any  number  of  synchronous  calls.  To 
show  this  we  present  an  algorithm  that  reduces  a  rule  containing 
any  number  of  synchronous  calls  to  a  set  of  rules  in  the  canoni¬ 
cal  form.  We  suggest  that  this  description  be  skipped  on  a  first 
reading. 

First,  rearrange  the  rule  so  that  it  has  the  form 

C  (V)  Al'  •••»  Am'  Bl»  **•'  Bn  (1) 

where  the  are  the  actions  containing  calls  and  the  B ^  are 
actions  not  containing  calls.  C  (V)  represents  a  cause  part  con¬ 
taining  the  free  variables 

V  =  Vi,  . .. ,  vf 

Number  all  the  calls  in  the  rule  (1)  from  1  to  N.  Invent  new 
private  names  r^,  rN  and  p-^,  . pN.  The  pi  will  be  the 

relations  used  to  receive  the  values  from  the  calls;  the  r^  will 
be  bound  to  the  returned  values.  Create  new  relations  II, 
and  The  relations  will  be  used  to  receive  the 

reply  relations  to  be  bound  to  p^ 

Replace  rule  (1)  by  the  rules: 
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c  (V)  TT  (V)  ,  B1,  ...»  Bn,  NewReK^),  ...»  NewRel(*N).  (2) 

*TT(v),  jrf1(p1),  ...»  *N(pM)  2('J).  O) 

2(U)  =»  Ax. 

(4) 

•  •  • 

Son  =>  an. 

=“»  .  (5) 

where  U  =  V,  p^»  ...»  p>j.  Rule  (2)  captures  the  parameters  in 
relation  II  ,  initiates  all  the  actions  that  do  not  contain  syn¬ 
chronous  calls  and  initiates  requests  for  N  new  reply  relations. 
(NewRel  is  a  public  relation  that  provides  previously  unused 
relation  IDs.)  Rule  (3)  receives  the  N  new  reply  relations  and 
combines  them  with  the  parameters  into  a  unique  activation  record 
in  the  5  relation.  (4)  denotes  a  set  of  rules  -  one  for  each 
action  containing  synchronous  calls.  These  rules  will  be  pro¬ 
cessed  in  later  steps  of  the  algorithm  to  eliminate  these  calls. 
Rule  (5)  will  be  modified  in  later  steps  of  the  algorithm  to  per¬ 
form  clean-up  functions  such  as  deleting  the  activation  record. 

For  each  rule  in  the  set  (4),  as  long  as  that  rule  contains 
a  synchronous  call,  write  the  rule  in  the  form 

5(?J)»  Pi^i^r  ...»  pm  ( rm)  ,  ...»  Ppjfr^)  ^  S  ( f  [ X] )  •  (6) 

where  by  E(f[X])  we  mean  an  action  containing  the  call  f[X], 
where  X  is  any  actual  parameter  list.  The  first  time  this  step 
is  performed  n  will  be  zero  (i.e.,  there  are  no  "p^(r^)"). 
Recall  that  at  the  beginning  of  the  algorithm  we  numbered  the 
calls  from  1  to  N;  suppose  that  f [X]  is  the  k-th  call.  Further, 
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suppose  that  the  conditions  have  been  reordered  so  that  r^, 
rm  occur  in  X  and  rm+1,  rn  occur  in  E(-).  Rewrite  rule  (6) 

as  these  two  rules: 


2(u) 

'  P 1  ( ^  i )  *  •  •  •  > 

Pm<rm>  f(X,pk). 

(7) 

2(U) 

'  Pm  +  1  ^  rm  +  1  ^ 

'  *  *  * '  Pn  (rn} '  Pk (rk} 

E(rk). 

(8) 

Rule  (7) 

initiates  the 

execution  of  f;  rule 

(9) 

waits  for 

its 

result  and  continues  the  execution  of  E. 

The  above  process  is  continued  until  there  are  no  more  calls 
in  the  set  (4).  Call  the  relations  updated  in  the  actions  A,, 
. Am  the  final  actions .  The  above  reduction  process  will 
result  in  m  rules  of  the  form  (8),  one  for  each  final  action: 

2(U),  p1(r1),  pn(rn)  =*  A t(Y).  (9) 

We  replace  each  of  these  rules  by: 

2(0),  Pi  ( r 1 ) '  •••»  pn ( rn)  A j ( Y) ,  A(p ^  r  •  •  •  r  pn )  •  (10) 

The  purpose  of  the  relation  A  is  to  signal  the  completion  of  the 
final  actions.  For  each  such  rule  (10)  created  we  add  the  condi¬ 
tion  *A(pi*  •••»  pn)  to  the  cause  part  of  rule  (5).  When  this 
has  been  done  for  all  the  final  actions,  the  modified  rule  (5) 
will  have  the  form: 

*2(0)  ,  *A(  •  •  •  t  P i t  ...),  *A  ( •  •  •  r  p  j  r  •••)  -  (11) 

When  each  of  the  m  final  actions  has  been  completed,  this  rule 
deletes  the  activat:  an  record  in  >  and  the  completion  signals  in 


When  this  algorithm  has  been  completed  we  will  have  a  set  of 
rules  with  this  structure  (rule  numbers  are  shown  in 
parentheses) : 

•  Creation  of  parameter  record  and  reply  relations  (2) 

•  Creation  of  activation  record  (3) 

•  Call  processing  (7,  8) 

•  Final  actions  (10) 

•  Destruction  of  activation  record  (11) 

6 . 4  Valueless  Procedures 

The  procedures  described  above  are  value  returning;  they 
return  a  value  that  is  used  in  the  expression  in  which  the  call 
occurs.  In  sequential  blocks  it  is  often  useful  to  have  value¬ 
less  procedures,  that  is,  procedures  that  have  an  effect  but  do 
not  return  a  value.  For  example,  the  block 

{  ...  ; 

Push [S , x ]  ; 

R(2)  } 

in  which  Push  is  valueless,  can  be  reduced  to  this  block: 

{  . . .  ; 


Push (S,x,p)  ; 


I 

; 

9 


1 


« 


. 


i 


L 


*p(y)  =*  R(2)  } 

In  this  case  *p(y)  waits  for  an  acknowledgement  and  ignores  the 
returned  value. 

6.5  Applicative  Expressions 

It  is  often  useful  to  be  able  to  evaluate  applicative 
(value-oriented)  expressions  in  the  effect  part  of  rules.  For 
example,  suppose  that  we  represent  name  directories  by  associa¬ 
tion  lists.  The  rules  to  put  names  in  these  directories  and  to 
look  up  their  values  can  be  written: 

*Def ine (d,n,x,a) ,  ^Contents (d,y) 

=>  Contents(  d,  cons  (  pair(n,x),  y) ) ,  a(d). 

*Lookup(d,n,a) ,  Contents (d , x)  =»  a (assoc (n,x) ) . 

In  the  second  rule  above  assoc  (n,x)  is  interpreted  as  an  applica¬ 
tion  of  the  function  assoc  to  the  values  n  and  x.  This  rule  can 
be  reduced  to  the  following,  which  explicitly  calls  for  the 
evaluation  of  the  expression: 

♦Lookup (d , n, a) ,  Contents  (d , x)  =*  a(  Eval [  assoc(n,x),  Current]  ) 

where  assoc  (n,x)  is  now  interpreted  as  a  simple  data  structure 
constructor  and  Current  is  the  current  environment. 

Since  a  rule  must  always  be  executed  to  completion  before 
another  rule  can  fire,  it  might  seem  that  the  effect  of  a  non¬ 
terminating  computation  would  be  to  hang  the  entire  system.  That 
this  is  not  the  case  can  be  seen  by  eliminating  the  synchronous 
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call  from  the  above  rule: 


*Lookup(d,n,a) ,  Contents (d,x) 

Eval  (  assoc(n,x),  Current,  p) ,  2(d»n,a,x). 

*p(y) »  *2(d#n,a,x)  a  (y) . 

If  Eval  never  returns  a  result  then  the  second  rule  will  never 

fire,  but  this  will  not  prevent  other  rules  from  firing.  Since 

all  rules  involving  applicative  expressions  ultimately  reduce  to 
rules  in  the  canonical  form  and  since  rules  in  the  canonical  form 
are  never  non-terminating,  we  can  see  that  execution  can  never  be 
stopped  by  non-terminating  applicative  expressions. 

6 • 6  Applicative  Conditions 

Consider  the  following  simulation  problem.  A  relation 
Sched(x,t)  means  that  an  event  x  is  scheduled  to  happen  at  time  t 

and  a  predicate  Clock  (t)  means  that  the  current  time  is  t.  We 

want  to  write  a  rule  to  cause  some  effect  S  whenever  the  clock 
time  is  at  least  as  late  as  the  time  at  which  an  event  is 
scheduled  to  happen.  We  allow  this  rule  to  be  written  as  fol¬ 
lows  : 


*Sched(x,t),  Clock(t')  if  t '  t  =»  E 

In  general  we  allow  any  Boolean-valued  applicative  expression  to 
appear  following  an  "if"  in  the  cause  part  of  a  rule.  To  illus¬ 
trate  the  reduction  of  these  rules  to  canonical  form  we  show  the 
reduction  of  the  scheduling  example: 


Sched(x,t),  Clock  (t  * )  ||(t'^t),  £(x,t,t’). 

*Sched(x,t),  Clock  (t ' )  ,  *7f  (true)  ,  *2(x,t,t')  E. 

♦TT(false),  *2 (Xf t( t 1 ) 

Here  ||  and  2  are  two  new  relations  associated  with  this  rule. 
Notice  that  the  relation  Sched  is  not  updated  until  after  the 
value  of  the  applicative  expression  t' ^t  has  been  returned  by 

Eval  and  is  known  to  be  true.  Also  notice  that  the  conditions  on 

Sched  and  Clock  are  retested  in  the  second  rule.  This  is  because 
they  may  no  longer  be  true  by  the  time  Eval  has  returned  its 
result. 

As  an  example  of  the  use  of  applicative  conditions  we 
present  a  simplified  form  of  the  file  system  described  in  David 
Reed's  thesis  [Reed78] .  Let  LastRead  ( r , t)  mean  that  record  r  was 
last  read  at  time  t  and  let  Value (r,t,x)  mean  that  the  value  of 
record  r  at  time  t  was  x.  The  value  of  r  at  any  time  T  can  be 

read  and  passed  to  an  action  A  by: 

Value  (r ,T,x) ,  LastRead (r,t) ;  T£t  =»  A(x). 

Value (r,T,x) ,  *LastRead { r , t) ;  T>t  =>  LastRead ( r , T) ,  A(x). 

Updating  a  record  r  to  a  new  value  y  effective  at  time  T  is 
denoted  by  Update (r,T,y) .  This  operation  is  only  allowed  if  r 
has  not  been  read  effective  at  a  later  time: 

Upda te ( r ,T ,y ) ,  LastRead { r , t) ;  T>t  =»  Value (r ,T,y) . 

Upda  te  ( r  ,T  ,y )  ,  LastRead  ( r  ,  t)  ;  T£t  =»  AbortUpdate  (T)  . 

The  purpose  of  AbortUpdate  is  to  clear  out  any  time  T  updates 
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that  might  have  already  been  made.  It  is  accomplished  by: 

AbortUpdate (T) ,  *Value (r ,T,x) 
else  *AbortUpdate (T) 

6.7  State  Variables 

Often  we  use  private  relations  to  refer  to  the  internal 
state  of  an  object.  For  example  loc(B,L)  might  mean  that  the 
screen  location  of  a  graphic  object  B  is  L.  It  is  often  con¬ 
venient  to  think  of  these  relations  as  state  variables  that  are 
private  to  the  object.  Consider  a  rule  such  as  this: 

Active  (self ) ,  loc(self,L),  *R(x)  =»  S(x,L). 

Clearly  L  represents  the  current  value  of  the  state  variable  loc. 
Therefore  we  allow  this  rule  to  be  abbreviated 

Active (self ) ,  *R(x)  «►  S(  x,  ?loc)  . 

In  general,  if  R  is  a  relation  and  @R  appears  in  an  action  of  a 
rule,  then  we  replace  @R  by  a  new  variable  v  and  place  the  condi¬ 
tion  R(self,v)  in  the  cause  part  of  the  rule.  Notice  that  this 
assumes  that  one  or  more  of  the  other  conditions  bind  "self." 
Often  this  is  the  "self"  bound  as  a  global  variable  in  the  cause 
part  of  a  sequential  block. 

Figure  1  shows  an  extended  example  using  all  of  these  abbre¬ 
viations.  It  is  part  of  the  definition  of  a  graphic  object  that 
appears  as  a  square  on  the  screen.  The  similarity  to  Smalltalk 
will  be  apparent  to  readers  familiar  with  that  language. 
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*Show(  self,  reply) 

{  Color!  @scribe,  black); 
Drawfself ) ; 
reply(self)  } 

♦Erase!  self,  reply)  => 

{  Color!  Ascribe,  background); 
Drawfself] ; 
reply(self)  } 

*Draw(  self,  reply)  =» 

{  Goto!  ascribe,  ^origin); 
Turn!  Ascribe,  §tilt); 
DrawAux [  self ,  0) ; 
reply(self)  } 

♦DrawAux!  self,  4,  reply)  =*  t 

♦DrawAux!  self,  k,  reply) 

{  Go[  ^scribe,  0size); 

Turn!  ascribe,  90); 

DrawAux!  @self,  k+l) ; 
reply(self)  } 


Figure  1.  Part  of  a  Graphic  Object 


reply(self)  else 


System  Structure 


In  this  section  we  iiscuss  a  possible  organization  for  an 
object-oriented  programming  system.  Although  this  is  not  the 
only  possible  organization,  it  will  illustrate  many  of  the 
characteristics  of  these  systems. 


Consider  the  problem  of  information  hiding,  that  is,  making 
the  corresponding  relations  visible  and  the  non-corresponding 
relations  invisible.  For  example,  in  the  definition  of  stacks, 
the  relations  NewStack,  Push,  Pop  and  Destroy  are  to  be  visible 
to  all  potential  stack  users,  while  the  relation  Contents  is 
visible  only  to  the  implementor  of  stacks.  This  is  accomplished 
by  placing  the  names  of  the  corresponding  relations  in  a  public 


I 

r 
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directory  while  keeping  "Contents"  in  the  private  directory  of 
the  implementor.  Suppose  that  all  environments  contain  at  least 
two  bindings:  "Private"  is  bound  to  the  private  directory  and 
"Public"  is  bound  to  the  public  directory.  Then,  using  the  rules 
for  directories  defined  in  Section  6.4  and  supposing  NewRelf] 
returns  a  new  relation  object,  we  can  define  the  private  relation 
Contents  by: 

Define!  Private,  "Contents",  NewRel[]  ]; 

The  distinction  between  public  and  private  relations  pro¬ 
vides  a  gross  level  of  discrimination  between  kinds  of  access.  A 
finer  level  of  discrimination  is  required  to  maintain  fidelity  to 
the  causal  model  of  objects.  For  example,  we  might  have  a  class 
of  objects  that  have  a  publicly  visible  attribute  Velocity.  The 
value  of  this  attribute  might  be  determined  by  non-corresponding 
causal  laws  private  to  this  class  of  objects.  Thus  it  makes 
sense  for  other  objects  to  inquire  the  value  of  this  attribute, 
but  not  to  alter  it.  With  just  the  public/private  distinction, 
we  only  have  two  choices:  (1)  make  the  attribute  private,  in 
which  case  other  objects  can  not  use  it  in  conditions,  or  (2) 
make  the  attribute  public,  in  which  case  it  is  vulnerable  to 
actions  by  other  objects. 

We  solve  this  problem  by  a  simple  form  of  capability  based 
addressing  [Dennis66].  We  assume  that  each  relation  is  denoted 
by  a  capability,  which  is  a  pair  <rs,id>  in  which  id  is  the 
object  identifier  for  the  relation  and  rs  is  the  set  of  access 
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rights  permitted  to  possessors  of  this  capability.  The  three 
possible  access  rights  correspond  to  the  possible  uses  of  rela¬ 
tions  in  rules:  read,  add  and  delete. 

When  a  relation  is  created  a  capability  bearing  all  rights 
is  returned.  Thus, 

Define[  Private,  "Push",  NewRel  []  ]; 

defines  the  private  name  "Push"  to  be  a  new  relation  that  can  be 
used  in  any  way.  To  restrict  access  to  relations  we  assume  the 
existence  of  procedures  RemoveR,  RemoveA,  RemoveD,  RemoveRD,  ... 
that  create  a  new  capability  that  is  like  a  given  capability 
except  that  it  has  certain  rights  removed.  Thus,  if  we  want  to 
define  a  public  name  "Push"  with  just  add-rights  that  is  the  same 
as  the  private  Push,  we  would  write: 

Definef  Public,  "Push",  RemoveRD [Push]  ]; 

The  capability  management  procedures  make  use  of  relations 
private  to  the  capability  manager;  these  rules  have  this  form: 

♦RemoveR  (c, a)  ,  Cmap(c,r),  Has(c,A),  Has(c,D),  *AvailCap(d) 

=*  Cmap(d,r),  Has(d,A),  Has(d,D),  a(d) 
else  *RemoveR  (c , a) ,  Cmap(c,r),  Has(c,A),  "AvailCap(d) 

=>  Cmap(d,r),  Has{d,A),  a(d). 
else  *RemoveR (c , a) ,  Cmap(c,r),  Has(c,D),  *Av3ilCap(d) 

=>  Cmap(d,r),  Has(d,D),  a(d). 

Figure  2  shows  a  complete  definition  of  stacks.  In  this  defini- 
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tion  we  have  used  a  procedure  NewRules[S]  which  takes  a  set  of 
rules  in  symbolic  form,  S,  associates  these  rules  with  a  new 
object,  activates  the  rules  and  returns  the  object.  The  result¬ 
ing  rule  object  is  given  a  private  name  to  allow  later  operations 
on  it  (such  as  editing  or  deactivating  the  rules). 


Define[  Private,  "NewStack",  NewRelf]  ]; 

Define!  Private,  "Push",  NewRel[]  ]; 

Definef  Private,  "Pop",  NewRelf]  ]; 

Definef  Private,  "Destroy",  NewRelf]  )? 

Define[  Private,  "Contents",  NewRelf]  j; 

Define[  Private,  "Rules",  NewRulesf 

' ‘NewStack  (a)  ,  *Avail(s)  Contents (s, nil) ,  a(s). 

♦Push  (s,x,a)  ,  ‘Contents (s ,y)  =»  Contents (s, cons (x,y) ) ,  a(s) 

*Pop(s,a),  ‘Contents  (s, cons  (x,y) )  =*►  Contents  (s  ,y)  ,  a(x). 

‘Destroy  (s , a) ,  ‘Contents  (s , x)  =>  a(x).  ']]; 

Define[  Public,  "NewStack",  RemoveRD [NewStack] ] ; 

Definef  Public,  "Push",  RemoveRD [Push] ] ; 

Definef  Public,  "Pop",  RemoveRD [Pop] ] ; 

Definef  Public,  "Destroy",  RemoveRD [Destroy] ] ; 

Figure  2.  Input  Commands  to  Define  Stack  Objects 

Interactive  programming  is  a  typical  situation  in  which  the 
object-oriented  viewpoint  is  preferable  to  the  value-oriented 
viewpoint.  Since  a  person  sitting  at  a  terminal  responds  to  con¬ 
ditions  and  takes  actions  in  time,  we  consider  a  person  to  be  an 
object.  To  allow  people  (real  objects)  to  interact  with  objects 
in  the  computer  (simulated  objects)  we  represent  people  by  surro¬ 
gates,  called  user  objects.  Therefore  users  can  be  put  into  and 
removed  from  relations  either  by  their  own  actions  or  by  the 
actions  of  other  objects  acting  on  the  users’  user  objects. 


The  user  object  is  atomic  as  far  as  the  users  are  concerned. 
At  a  lower  level  of  abstraction  (the  system  level)  the  user 
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object  resolves  into  a  number  of  smaller  objects  representing  the 
display  screen,  the  keyboard,  the  directories  etc. 

In  their  interactions  with  the  rest  of  the  system  user 
objects  act  like  any  other  objects.  However,  because  these 
objects  act  as  proxies  for  people  they  have  some  special  charac¬ 
teristics.  Since  the  future  action  of  users  cannot  be  defined  by 
a  finite  set  of  rules,  the  system  must  provide  a  way  of  interact¬ 
ing  with  users.  This  includes  methods  of  informing  them  of  the 
relations  that  hold  on  their  user  objects  and  means  for  allowing 
them  to  direct  their  user  objects  to  take  actions.  Both  of  these 
can  be  accomplished  by  allowing  users  to  enter  rules  or  parts  of 
rules. 


To  account  for  the  fact  that  users  might  never  repeat  their 
actions  under  the  same  conditions,  the  commands  that  users  type 
are  formally  considered  to  be  part  of  an  open-ended  sequential 
block.  Thus  each  command  is  implicitly  parameterized  by  an 
ever-changing  attribute  that  can  be  thought  of  as  time.  The 
definitions  shown  in  Figure  2  are  typical  commands  that  a  user 
might  type  at  a  terminal. 

All  the  commands  in  Figure  2  are  synchronous  calls  -  the 
action  must  be  completed  {or  aborted)  before  the  user  can  con¬ 
tinue.  Parallel  activities  can  be  initiated  by  simple  uncondi¬ 
tional  actions,  for  example: 

Compile (  Progl,  Replyl)  ,  Compile (  Prog2,  Reply2) ; 
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The  user  can  also  type  actionless  conditions,  e.g.. 


Replyl (result)  ; 

which  causes  the  user  task  to  pause  until  the  conditions  are 
satisfied.  Complete  rules  are  useful  for  recovering  results  from 
parallel  tasks,  e.g., 

*Replyl (result)  =»  Define[  Private,  "Binary",  result]; 

Since  applicative  expressions  are  allowed  as  parts  of  actions 
users  can  also  call  for  the  evaluation  of  applicative  expres¬ 
sions  : 

Display [  f ac (3)  ] ; 

6 

Thus  the  command  language  is  the  same  as  the  object-oriented 
language;  the  value-oriented  language  is  embedded  in  the  object- 
oriented  language.  This  seems  to  be  the  best  relationship  of 
object-  and  value-oriented  languages;  it  can  be  seen  in  several 
existing  systems  (e.g.,  LISP  and  Backus's  AST). 

8 .  Formal  Semantics 
3.1  Abstract  Syntax 

In  this  section  we  present  a  formal  semantics  for  the  execu¬ 
tion  of  condition-action  rules.  (The  casual  reader  is  advised  to 
skip  this  section.)  The  formal  semantics  will  be  expressed  as  a 
series  of  function  definitions  that  define  a  mapping  from 
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abstract  rules  into  state  transition  functions.  The  abstract 
syntax  for  rules  is  shown  in  Figure  3;  the  correspondence  between 
the  abstract  and  concrete  syntaxes  should  be  obvious. 


rule 

cause 

effect 

predicate 

constructor 

item 


cause  effect 
predicate  + 
predicate  + 

name^constructor  +  -  name  constructor 

item 

name  +  constant  +  constructor 


Figure  3.  Abstract  Syntax  for  Rules 
8.2  State  Space 


As  discussed  in  Section  2  (Intension  versus  Extension) 
intensionally  different  relations  are  distinguished  by  having 
different  IDs.  Since  the  extensions  of  intensional  relations  can 
change  in  time,  a  state  is  considered  a  mapping  from  IDs  into 
extensional  relations.  The  definition  of  the  state  space  is 
shown  in  Figure  4. 


states 

relations 

tuples 

elements 

objects 


IDs  -»  relations 
P (tuples^ 
elements 

objects  +  values  +  tuples 
atomic-ob jects  +  relation-objects 


where  P(s)  denotes  the  powerset  of  the  set  s. 

Figure  4.  The  State  Space 

Recall  that  relations  are  manipulated  through  capabi 1 i t ies 
that  control  read,  add  and  delete  access  to  the  underlying  rela¬ 
tions.  Therefore  we  define  the  set  relat ion-ob j ects  to  be  the 
set  of  all  capabilities.  This  set  has  three  exhaustive  but  not 
mutually  exclusive  subsets. 
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ReadCaps,  AddCaps,  DeleteCaps  C  relation-objects 


relation-objects  3  ReadCaps  U  AddCaps  U  DeleteCaps 

Note  that  a  capability  that  bears  multiple  rights  (e.g.,  add  and 
delete)  will  be  a  member  o£  several  of  these  sets  (e.g,,  AddCaps 
and  DeleteCaps).  The  function  Cmap  takes  a  capability  to  its 
underlying  relation  ID: 

Cmap:  relation-objects  -»  IDs 

These  notions  are  formally  defined  in  Figure  5. 

rights  3  {R,  A,  D) 

rights-sets  3  P(rights) 

relation-objects  3  rights-sets  X  IDs 


Cmap (r ) 

ReadCaps 

=  2(r) 

3  Tc  t 

relation-objects  1 

I  R 

t 

1 

(c) } 

AddCaps 

3  {c  e 

relation-objects 

I  A 

C 

I 

(c)  } 

DeleteCaps 

3  {c  < 

relation-objects 

1  D 

€ 

1 

(c)  } 

Figure  5.  Capabilities 
8 . 3  Multiple-valued  Functions 

Our  goal  in  this  section  is  to  define  a  state  transition 
function  for  condition-action  rules.  Notice,  however,  that  the 
execution  of  rules  is  in  general  non-deterministic .  That  is, 
from  the  current  state  the  state  transition  function  may  define 
several  successor  states.  In  other  words,  the  state  transition 
function  is  multiple  valued.  What  this  means  of  course  is  that 
we  have  a  state  transition  relation  rather  than  a  state  transi¬ 
tion  function.  Although  we  will  define  a  relation  Cycle 
6  states  X  states  such  that  Cycle(s,s')  is  true  if  and  only  if  s’ 
is  a  possible  successor  state  of  s,  it  will  often  be  more  con- 
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venient  to  think  of  Cycle  (s)  as  a  multiple-valued  function.  This 
will  allow  us  to  use  a  more  familiar  functional  notation  in  our 
definitions.  Unless  specified  otherwise,  in  the  following  sub¬ 
sections  "function"  will  refer  to  both  single-valued  and 
multiple-valued  functions. 

Since  we  will  be  dealing  with  multiple-valued  functions,  it 
will  be  necessary  to  talk  about  sets  of  multiple-valued  func¬ 
tions.  We  write  D  R  for  the  set  of  all  multiple-valued  func¬ 
tions  with  domain  D  and  range  R.  This  notation  is  analogous  to 
D  -»  R,  the  set  of  all  single-valued  functions  from  D  into  R. 
Of  course  mathematically  D  R  is  just  DXR,  but  our  notation 
will  better  emphasize  the  functional  viewpoint. 

Although  we  introduce  additional  notation  as  we  need  it,  the 
reader  can  find  a  complete  description  of  the  functional  and 
relational  operators  we  use  in  [MacLennan8 1 ]  and  [MacLennan83] . 

8 . 4  Semantics  of  Rules 

Our  goal  in  the  following  sections  is  to  define  a  function 
Cycle:  states  =»  states 

that  describes  the  non-deterministic  transition  from  state  to 
state.  We  will  do  this  by  first  defining  a  single-valued  func¬ 
tion 

Rule:  rule  -»  envs X  states  =»  states 
that  takes  rules  into  multiple-valued  functions  that  take 
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environment-state  pairs  into  states.  Note  that  the  arrows  are 
right  associative  and  less  binding  than  the  cross.  We  use  the 
convention  of  writing  the  names  of  abstract  syntactic  categories 
in  lowercase  (e.g.f  "rule")  and  the  names  of  the  corresponding 
semantic  functions  with  a  leading  uppercase  letter  (e.g., 
"Rule") . 

We  will  define  the  Rule  function  in  a  top-down  order.  The 
effect  of  the  cause  part  of  a  rule  is  to  test  for  the  cause  being 
true  of  the  state  and,  if  it  is,  to  extend  the  environment  by  the 
names  bound  in  the  pattern  matching  process.  This  extended 
environment  is  then  used  during  execution  of  the  effect  part  of 
the  rule.  The  definition  of  Rule  is: 

Rule [c,e] (E,s)  =  Effect[e]  £'  s 
where  E1  *  Cause[c]  s  E 

where  c  and  e  are  the  cause  and  effect  parts  of  the  rule  and  E' 
is  the  extended  environment.  Note  that  function  application  is 
assumed  to  be  left  associative;  thus  Fxy  means  (Fx)y. 

We  first  address  the  effect  part  of  a  rule  because  it  is  a 
little  simpler.  The  type  of  Effect  is: 

Effect:  effect  ->  envs  -»  states  =»  states 

The  effect  part  of  a  rule  is  composed  of  a  series  of  actions  that 
are  executed  in  order  in  the  given  environment.  Thus  the  state 
transition  function  defined  by  the  effect  is  just  the  composition 
of  the  state  transition  functions  defined  by  its  constituent 


actions: 


Effect [ f  A  2 ,  •  •  •  t  Afi]  G 

*  (Action [An] E)  *  ...  *  (Action [A2] E)  *  (Action [A^] E) 

There  are  two  kinds  of  actions:  additions  and  deletions. 

The  type  of  their  semantic  function  is 

Action:  predicate  -»  envs  ->  states  =♦  states 

To  process  an  addition,  nc,  whose  name  part  is  n  and  whose  con¬ 
structor  part  is  c,  we  must  evaluate  c  in  the  current  environment 
and  add  it  to  the  relation  that  results  from  looking  up  n  in  the 
current  environment.  The  updated  relation  is 

(s*Cmap*E]n  (J  {Constructor  [c]  E} 

where  s  is  the  current  state,  Cmap  is  the  capability  mapping 
function  and  E  is  the  current  environment.  This  new  relation 
must  replace  the  old  value  associated  with  the  relation  ID  in  the 
state.  We  use  [x:y]/f  to  mean  a  function  like  f  except  that  x  is 
mapped  to  y.  Therefore  the  new  state  is  defined  by 

Action[nc]Es  = 

[  ( [AddCaps  -*  Cmap]  (En)  )  :  ([s*Cmap*E]n  U  {Constructor  [c]  E} )] /s 

Here  AddCaps -» Cmap  is  the  capability  mapping  function  with  its 
domain  restricted  to  add-capabilities,  since  s  -»  f  means  the 
function  f  with  its  domain  restricted  to  s.  This  ensures  that  we 
do  not  add  to  a  relation  unless  we  have  an  add  capability  for  it. 
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The  semantics  for  deletions  is  analogous: 


Action[-nc] Es  * 

[  ( [DeleteCaps -»  Cmap]  (En) )  :  ([s*Cmap*E]n  -  {Constructor  [c]  E} )]  /s 

The  formal  semantics  for  constructors  is  straight-forward: 

Constructor:  constructor  -»  envs  ->  tuples 
Constructor [ item^  ...  itemn]E 

*  <Item[itera^] E,  ...  ,  Item[itemn] E> 

Item:  item  -»  elements 

Item[name]E  =  E{name) 

Item [constant] E  =  constant 

Item[constructor]  =  Constructor [constructor ] 

Next  we  address  the  cause  part  of  rules.  The  type  of  the 
semantic  function  for  causes  is: 

Cause:  cause  -»  states  envs  =»  envs 

As  expected,  cause  parts  leave  the  state  unchanged  but  (tem¬ 
porarily)  modify  the  environment.  The  semantics  of  a  cause  is 
just  the  composition  of  the  semantics  of  its  constituent  condi¬ 
tions  : 


Cause [C^ ,  C2 ,  ...  ,  CnJ  s 

=  (Cond[Cn]s)*  ...  •  (Cond[C2]s)  *  (Cond  [CjJ  s) 

The  semantics  of  conditions  is  defined  by  the  function  Cond: 

Cond:  condition  -»  states  -»  envs  =*  envs 
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First  we  address  the  semantics  of  positive  conditions, 
Cond[nc]sE,  where  n  is  the  name  of  a  relation  and  c  is  a  con¬ 
structor.  To  accomplish  this  we  define  a  function 

match:  constructor  relations  ->  envs  =*»  envs 

that  will  determine  if  the  pattern  c  occurs  in  the  relation  that 
is  the  meaning  of  n  in  the  current  environment  and  state.  Thus, 

Cond[nc]sE  =  match  [c]  (ReadRel  s  E  n)E 

where  (ReadRel  s  E  n)  is  a  (readable)  relation  whose  name  is  n  in 
the  environment  E  and  the  state  s: 

ReadRel  s  E  =  s  *  [ReadCaps  -»  Cmap]  *  E 

Next  consider  match [c] RE;  this  must  determine  if  the  pattern 
c  occurs  in  the  relation  R  and,  if  it  does,  return  an  environment 
that  is  an  extension  of  E  that  includes  the  bindings  made  by  the 
pattern  matching  process.  Now,  suppose  we  have  a  function  Fin- 
dEnvs : 

FindEnvs:  relations  -»  envs  -»  P(envs) 

such  that  FindEnvs [c] RE  returns  all  extensions  of  E  that  can 
result  from  matching  c  in  R.  We  want  match  to  be  a  multiple¬ 
valued  function  that  can  return  any  one  of  these  extensions  of  E. 
Therefore,  define 

match  =  C  ™ ^'FindEnvs 

where  €  (x)  is  any  set  containing  x  so  C  ”^(S)  is  a  multiple- 
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valued  function  that  returns  any  element  of  the  set  S. 

Consider  the  function  Constructor  [c] E;  this  evaluates  the 
constructor  c  in  the  environment  E  to  yield  a  tuple  t.  Therefore 
(Constructor [c] )  ”^t  is  any  environment  in  which  the  evaluation 
of  c  yields  t.  Therefore  (Constructor  [c] )  matches  the  pattern 
c  against  a  tuple  and  yields  any  environment  that  allows  the 
match  to  succeed.  Its  type  is 

(Constructor  [c]  )  _i:  tuples  ***  envs 

If  unimg[f]x  represents  the  set  of  all  y  such  that  f(x,y)  then 
unimg [ (Constructor [c] )  “*]t  is  the  set  of  ell  such  environments 
and  its  type  is 

unimg ( (Constructor  [c] )  -1]:  tuples  =»  P(envs) 

Mow  suppose  that  we  have  a  function  (defined  later) 

minext:  envs  -»  P(envs)  =>  P(envs) 

such  that  minext  E  S  is  the  set  of  all  the  minimum  extensions  of 
E  that  are  in  S.  It  is  then  easy  to  see  that 

f«  -1  *  (minext  E)  '  unimg  [  (Constructor  [c] )  ~1]}t 

is  any  minimum  extension  to  E  that  results  from  matching  pattern 
c  against  tuple  t.  Now,  if  img[f]S  is  the  set  of  all  y  such  that 
for  some  xCS  we  have  f(x,y),  then  it  is  easy  to  see  that 

img[f  ‘  (minext  E)  *  unimg  (  (Constructor  [c]  )  -1]]R 


] 
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is  the  set  of  all  extensions  to  E  that  can  result  from  matching  c 
against  any  tuple  in  R.  Simplifying  this  expression  we  get  our 
definition  for  FindEnvs: 

FindEnvs [c] RE  =  [ (minext  E)  *  img [ (Constructor [c] )  ”  1 ] ] R 

It  remains  to  define  minext  E  S,  the  subset  of  S  containing 
the  minimum  extensions  of  E.  Observe  that  unimgtCJE  is  the  set 
of  all  supersets  (extensions)  of  E.  Therefore 

S  ft  unimg[C]E 

is  the  subset  of  S  containing  just  extensions  to  E.  We  want  to 
find  the  minimum  elements  of  this  set,  which  is  just  the  initial 
members  of  the  subset  relation  restricted  to  this  set: 

minext  E  S  *  initC  C  T  (S  ft  unimg[C)E)  ] 

This  completes  the  definition  of  positive  conditions. 

The  semantics  of  negative  conditions  is  simpler  than  posi¬ 
tive  conditions.  First  define 

Cond[-nc]sE  *  nomatch  [c]  (ReadRel  s  E  n)S 

Negative  conditions  are  simpler  because  they  don’t  update  the 
environment.  Therefore,  nomatch[c]R  is  just  an  identity  function 
restricted  to  those  environments  in  which  c  doesn't  match  a  tuple 
in  R.  Recall  that  FindEnvs [c] RE  is  the  set  of  all  extensions  to 
E  such  that  c  matches  a  tuple  in  R.  Therefore,  if  FindEnvs [c] RE 
*  i  then  there  are  no  such  environments;  in  other  words  c  does 
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not  match  any  tuples  in  R.  Thus,  the  set  of  all  environments  in 
which  c  doesn't  match  a  tuple  in  R  is  the  inverse  image  of  the 
empty  set  under  FindEnvs [c] R.  By  using  this  set  to  restrict  the 
domain  of  the  identity  function  we  get  the  definition  of  nomatch: 

nomatch[c]R  =  [unimg  (FindEnvs  [c]  R)  -»  Id 

where  Id  is  the  identity  function. 

8 . 5  Semantics  of  Execution 

We  have  now  described  the  semantics  of  an  individual  rule; 
it  remains  to  define  the  state  transition  semantics  of  the  entire 
system.  Recall  that  a  rule  has  to  be  evaluated  in  the  proper 
environment.  Therefore  we  postulate  the  existence  of  an  ID 
p  C  IDs  such  that  sp(i,r,E)  means  that  i  is  the  ID  of  a  rule  r 
that  must  be  evaluated  in  environment  E.  Hence, 

sp:  Ids  rule  X  envs 

Next  we  define  a  function  Trans  i  s,  which  means  a  transition  of 
state  s  by  rule  object  i: 

Trans:  IDs  -»  states  states 

Trans  i  s  =  Rule[r](E,s)  where  (r,E)  =  spi 

Thus  Trans(i)  is  the  state  transition  function  for  rule  object  i. 

To  complete  the  state  transition  semantics  we  need  a 
multiple-valued  function  Cycle  such  that  Cycle  (s)  is  any  state 
that  follows  immediately  from  s.  Thus, 
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Cycle:  states  ^  states 


We  want  Cycle (s, s')  to  be  true  if  there  is  any  rule  object  i  such 
that  Trans [i] (s,s ') .  Now,  Rng  Trans  is  the  range  of  Trans,  i.e., 
the  set  of  all  Trans[i]  for  any  i.  Therefore  U  (Rng  Trans)  com¬ 
bines  all  of  these  individual  transition  functions  into  one. 
Cycle  can  now  be  defined: 

Cycle  =  U (Rng  Trans) 

Notice  that  Cycle  (s, s')  means  that  state  s  can  lead  to  state 
s'  in  one  transition;  we  would  like  to  extend  this  to  repeated 
transitions.  Notice  however  that  object-oriented  systems  are 
often  non-terminating  and  non-deterministic,  therefore  their 
denotational  semantics  can  not  take  the  form  of  a  single-valued 
function.  Rather,  a  denotational  semantics  for  an  object- 
oriented  system  is  a  relation  that  relates  past  states  to  possi¬ 
ble  future  states.  Defining  this  relation  is  our  next  task. 

Let  Cycle*  be  the  reflexive  transitive  closure  of  the  rela¬ 
tion  Cycle;  then  Cycle*(s,s')  means  that  state  s  can  lead  to 
state  s'  in  zero  or  more  transitions.  Thus  we  define  CanReach  = 
Cycle*  so  that  CanReach (s , s ' )  means  that  state  s  can  lead  to 
state  s'. 

The  definition  of  CanReach  is  too  permissive  for  many  pur¬ 
poses  since  CanReach  (s , s ' )  is  true  if  there  is  any  set  of  inter¬ 
mediate  states  that  will  get  us  from  s  to  s'.  Sometimes  we  want 
to  know  if  a  state  can  lead  to  another  state  that  is  a  dead  end. 
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i.e.,  that  we  can't  get  out  of.  We  can  express  this  idea  as  fol¬ 
lows.  Let  co:..*t(X)  represent  a  constant  function  that  always 
returns  a  distinguished  value,  Then  extend  Cycle  to  a  total 
function 


Cycle  /  const  (X) 

so  that  [Cycle/const (X)  1 s  is  X  if  Cycle (s)  is  undefined.  Notice 
also  that  this  total  function  is  X  preserving.  Now  consider  the 
relation 

Reaches  =  [Cycle  /  const (X) 1  * 

If  Reaches  (s,X)  then  we  know  that  s  can  lead  to  an  state  that  we 
can't  get  out  of.  If  this  is  not  true,  then  Reaches (s , s ' )  means 
that  s  can  safely  reach  s'. 


9 .  Summary 


Several  similarities  will  have  been  observed  between  this 
work  and  previous  work.  For  example,  in  [Lomet76]  and  [Lomet80] 
David  Lomet  describes  a  distinction  between  values  and  objects 
that  is  very  similar  to  ours.  We  recommend  these  papers  to  the 
reader  as  an  interesting  alternate  approach  to  the  value/object 
distinction.  However,  we  believe  that  our  simulation  based 
notion  of  an  object  is  more  fundamental  than  Lomet's  storage 
based  idea. 


on 


As  has  been  noted,  the 
a  finite  universe  of 


idea  of  a  set  of  alterable  relations 
objects  is  similar  to  the  knowledge 
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representation  networks  used  in  artificial  intelligence  applica¬ 
tions  and  the  set  of  causal  laws  has  similarities  to  both  produc¬ 
tion  systems  and  PROLOG  programs.  A  fundamental  difference 
between  our  work  and  these  systems  is  that  our  notion  of  a  pro¬ 
duction  does  not  require  any  backtracking.  Furthermore,  we  know 
of  no  other  attempt  to  make  these  ideas  the  basis  of  an  entire 
programming  system. 

This  paper  extends  previous  work  in  several  areas.  First, 
it  clarifies  the  nature,  purpose,  and  roles  of  values  and  objects 
in  programming  languages.  Second,  it  argues  that  objects  are 
important  programming  devices  and  should  be  included  in  applica¬ 
tive  languages.  Finally,  it  proposes  a  specific  form  in  which 
objects  can  be  accommodated.  This  includes  the  distinction 
between  corresponding  and  non-corresponding  objects  and  rela¬ 
tions,  and  the  use  of  name  contexts  and  capabilities  to  hide 
non-corresponding  objects  and  relations.  Finally,  it  proposes 
that  the  manipulation  of  objects  be  specified  by  causal  laws  that 
determine  sets  of  transactions  to  alter  the  state.  It  is  shown 
how  these  concepts  may  be  combined  with  applicative  programming 
ideas. 
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